大模型提示词工程
1. 大白话：这是什么？解决什么痛点？
提示词工程不是“把话说得好听一点”，而是把人类意图翻译成大模型更容易稳定执行的输入协议。大模型本质上是在给定上下文里预测下一个 token，如果只给一句模糊需求，它可能答非所问、格式乱飞、遗漏约束，甚至在 Agent 场景里调用错误工具。所以提示词工程的核心目的，就是缩小模型的搜索范围，把“我要什么、不要什么、按什么步骤想、输出成什么结构、遇到异常怎么兜底”提前讲清楚。
一个合格的 Prompt 通常包含四个要素：
- Role：让模型站在什么身份回答，比如“资深 Java 架构师”。
- Task：明确要完成什么动作，比如“识别用户意图并抽取槽位”。
- Context：提供任务相关背景，比如业务规则、用户状态、检索证据、工具返回。
- Format：规定输出长什么样，比如 JSON 字段、枚举值、Markdown 段落。
它主要解决三个痛点：
- 意图不稳定：同一个问题换个说法，模型可能理解成不同任务。通过角色、目标、边界条件和示例，可以把模型的回答方向拉稳。
- 信息噪声太多：Prompt 不是越长越好。无关背景堆太多，会增加延迟和 token 成本，也会让模型抓不住重点。
- 输出不可控：业务系统通常需要 JSON、枚举、固定字段或可解析文本，而不是一段自由发挥的作文。提示词要配合结构化输出约束，让后端能可靠解析。
- Agent 行为失控：一旦模型可以调用工具，提示词就不只是“让模型回答”，还要约束它什么时候调用工具、调用哪个工具、工具失败后怎么处理，防止乱调、漏调和循环调用。
一句话总结：提示词工程是大模型应用的第一层控制面，目标不是让模型“更聪明”，而是让它在有限上下文里更稳定、更可解析、更符合业务边界。
2. 底层机制与高频考点
底层机制
上下文窗口决定模型能看到什么 大模型不会记住系统外的信息，它只能基于当前输入上下文生成答案。所以提示词需要把当前任务必需的信息组织进去，包括系统角色、业务规则、用户问题、工具说明、历史摘要和输出格式。信息太少会幻觉，信息太多又会稀释重点，甚至出现 Lost in the Middle。
实战里可以把关键角色和全局边界放在开头，把输出格式、校验规则、最终回答要求放在结尾，降低中间信息被忽略的概率。但这不是死公式，最终要靠样例评测验证。
指令层级决定冲突时听谁的 常见输入会分成 system、developer、user、assistant、tool 等不同角色。面试可以这样说：越靠近系统侧的指令优先级越高，业务约束、隐私边界和工具调用规则应该放在更高优先级的提示中；用户输入里可能包含 prompt injection，不能让它覆盖系统规则。
结构化输出降低后端解析成本 在工程里，很多提示词会要求模型输出 JSON、固定枚举、置信度、reason 字段或 function call 参数。这样后端可以做 schema 校验、参数补全、失败重试和降级，而不是用正则去猜模型到底想表达什么。
但“请返回 JSON”只是自然语言约束，不是强约束。更稳的是使用模型或框架支持的原生 Structured Outputs，把 JSON Schema 作为 API 参数传入；即便如此，服务端仍要做 schema 校验、枚举越界处理和失败重试。
少样本示例提升格式和边界稳定性 Few-shot prompting 的核心价值不是堆资料，而是给模型“输入到输出”的范式样本。尤其是分类、意图识别、槽位抽取、客服话术、工具选择这类任务，给 2 到 3 个正反例通常比长篇规则更稳定。
链式提示让复杂任务可调试 对多步骤分析、合同审查、代码评审、Agent 规划这类复杂任务，不要总想着一条 Prompt 解决全部问题。可以拆成 Prompt Chaining：第一步识别意图，第二步抽槽位，第三步生成工具调用计划，第四步校验输出。这样哪一步出错，就能单独定位和回归。
高频面试对比考点
考点一：Prompt Engineering vs Context Engineering
- Prompt Engineering：重点是“指令怎么写”，比如角色、任务、约束、输出格式、示例。
- Context Engineering：重点是“把哪些信息在什么时机喂给模型”，包括 RAG 检索结果、用户画像、短期记忆、工具描述、历史摘要和 token 预算控制。
- 面试里的高分表达：Prompt 是指令层，Context 是供给层。单靠提示词无法解决长上下文、检索噪声、工具过载和历史膨胀问题，生产级 Agent 更依赖上下文工程。
考点二：提示词工程 vs 微调
- 提示词工程：成本低、迭代快、适合业务规则经常变化的场景，但稳定性依赖模型能力和上下文质量。
- 微调：适合固化大量领域表达风格、分类边界或专有任务模式，但训练和评估成本更高，且不适合频繁变化的实时业务知识。
- 常见取舍：先用提示词和 RAG 做快速验证，只有当任务模式稳定、样本充足、提示词成本过高或一致性仍不达标时，再考虑微调。
考点三：Chain-of-Thought vs 可控推理
- 面试中不要简单说“让模型输出思维链”。工程上更常见的是让模型在内部分步判断，但最终只输出结论、关键依据和结构化字段。
- 对高风险业务，比如退款、取消订单、支付状态，不能只信模型推理，要把关键判断下沉到代码、规则引擎或数据库强校验。
考点四：Prompt Injection vs Jailbreak
- Prompt Injection：攻击来源通常是不可信外部内容，比如网页、邮件、文档、RAG 片段、工具返回，目标是覆盖应用原本的系统指令。
- Jailbreak：攻击来源通常是用户直接输入对抗性指令，目标是绕过模型安全策略。
- 防御方式不能只靠提示词里写“不要违规”。要用 XML 标签或分隔符隔离不可信内容，并在代码层做权限校验、工具白名单、参数校验、沙箱隔离、审计日志和高危操作二次确认。
考点五：Agent 工具调用提示词怎么设计
工具调用提示词不能只写“你可以调用这些工具”，还要写清楚：
- 什么时候必须调用工具，什么时候直接回答；
- 每个工具的参数含义、必填字段和失败语义；
- 调用前是否需要补问用户；
- 多工具调用的顺序；
- 工具返回为空、失败或冲突时如何降级；
- 禁止重复调用同一工具解决不了的问题。
考点六：Demo Prompt vs 生产级 Prompt 管理
- Demo 阶段可以把 Prompt 写成代码里的字符串，只要能跑通即可。
- 生产级 Prompt 应当当成可版本化配置管理：支持模板版本、变量注入校验、灰度发布、快速回滚、审计记录、线上 trace 绑定和失败样例回放。
- 高频答法：Prompt 变更会影响输出质量、工具调用、检索策略、成本和安全边界，所以它不是文案，而是生产配置。
3. 🎯 实战口径
面试官提问：你在项目里是怎么做提示词工程的？它和普通写 Prompt 有什么区别？
我的回答可以这样组织：
“在我的 苍穹外卖 AI 智能客服 Agent 项目里，我对提示词工程的理解不是简单写一段角色设定，而是把它作为 Agent 调度链路里的一层行为约束。我们用 Spring AI Advisor 链把用户上下文、意图识别、对话记忆、RAG 检索结果、工具白名单和安全兜底分层注入给大模型，每一层都只提供当前任务需要的信息，避免把所有规则和工具一次性塞进上下文导致模型选择混乱。
具体落地上，我主要做了四类控制。第一类是四要素拆分：每类业务场景都明确 Role、Task、Context、Format，避免模型自己猜角色和输出粒度。第二类是意图和工具边界控制：比如用户问订单状态时，只开放订单查询相关工具；用户只是问 FAQ 时，优先走本地语义缓存或 RAG，而不是让模型随便调用业务接口。第三类是结构化输出控制：对意图识别、槽位抽取、多步任务规划这类场景，我要求模型输出固定 JSON 字段，再由 Java 端做 schema 校验和参数补全。第四类是失败兜底控制：如果参数不足，提示词要求模型先追问，而不是猜；如果工具返回失败，就给出可解释的客服话术。
我踩过的坑是，单靠提示词约束不了所有失控行为。比如模型在模糊订单问题下可能反复用相同参数调用 getOrderDetail，造成工具调用死循环和 token 浪费。所以我在 Advisor 链最后加了 SafeToolCallAdvisor，用 toolName + arguments 生成调用签名，一旦发现重复签名或者工具调用超过 4 轮，就直接短路返回兜底话术。后续如果要继续生产化，我还会把 Prompt 从代码字符串升级成版本化配置，记录 Prompt 版本、模型参数、输入变量摘要和失败样例，方便灰度、回滚和离线评测。也就是说，我的设计不是把稳定性完全寄托在 Prompt 上，而是采用‘提示词约束 + 上下文过滤 + 工具白名单 + 代码熔断 + 版本化治理’的组合，把不可控的大模型行为收敛成可上线的工程链路。”
相关链接：[[苍穹外卖AI客服]] | [[AI Agent 核心概念]] | [[AI Agent 记忆系统]]